feat(release): native windows/arm64 binary and PyPI wheel#598
Conversation
roborev: Combined Review (
|
Documents native Windows-on-ARM support in the Quick Start install section: - **pip / uvx** -- adds `arm64` to the published Windows PyPI wheels. - **Shell Script** -- notes that the installer prefers the native `arm64` build and otherwise falls back to the `x86_64` build under Windows' x64 emulation, with a pointer to build-from-source. - **Build from source** -- new "Windows on ARM" subsection: `make` isn't available on Windows and CGO needs an `aarch64`-targeting compiler, so it walks through Go for Windows/ARM64 + the llvm-mingw aarch64 toolchain, the manual frontend embed, and `go build -tags fts5`. Pairs with kenn-io/agentsview#598 (native windows/arm64 release binary + `win_arm64` wheel) and kenn-io/agentsview#597 (installer arm64 handling). The PyPI arm64 wheel becomes available once a release ships #598; the build-from-source steps work today.
Add windows/arm64 to the release matrix on a native windows-11-arm runner. cgo (mattn/go-sqlite3 + fts5) needs a C compiler, so set up a self-contained llvm-mingw aarch64 toolchain (clang + runtime + lld; no Visual Studio / Windows SDK) and build with CC pointed at it. The build runs on real ARM hardware so the existing --version smoke test executes natively. Packaging keeps using 7-Zip (preinstalled on the image). Also publish a matching win_arm64 PyPI wheel: add windows_arm64 -> win_arm64 to build_wheels.py PLATFORM_MAP so `pip install agentsview` works natively on Windows on ARM. With --require-all the release now expects this artifact, which the new matrix entry produces. Validated on Windows 11 arm64: frontend build, cgo+fts5 go build, native --version smoke test, and a win_arm64 wheel containing an ARM64 PE all succeed. build_wheels_test.py: 46 passed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
wesm
force-pushed
the
feat/windows-arm64-release
branch
from
2fd2c61 to
4f1919c
Compare
roborev: Combined Review (
|
The windows/arm64 build downloads the llvm-mingw archive and runs it as the cgo C compiler, then publishes the resulting binary to the GitHub release and a PyPI wheel. Check the archive against a pinned SHA256 before extracting or executing it, so a swapped or compromised upstream asset fails the build instead of producing a trojaned binary.
roborev: Combined Review (
|
## Summary
duckdb-go-bindings ships prebuilt static DuckDB libraries only for darwin/{amd64,arm64}, linux/{amd64,arm64}, and windows/amd64. Since #609 the DuckDB driver links into every binary unconditionally, and since #598 the release workflow builds a native windows/arm64 binary — a combination that has never run together: linking `cmd/agentsview` for windows/arm64 fails with undefined `duckdb_*` symbols, which would fail the `build` matrix and block the entire next release (the `release` and `pypi` jobs need every leg, and `build_wheels.py --require-all` expects a windows_arm64 archive).
Driver registration now goes through an `openDuckDB` shim:
- `internal/duckdb/driver.go` (`!(windows && arm64)`) blank-imports `github.com/duckdb/duckdb-go/v2` and opens connections as before.
- `internal/duckdb/driver_windows_arm64.go` returns a clear unsupported-platform error from `Open` and `NewQuackStore` instead of linking the driver. The rest of the `internal/duckdb` package is plain `database/sql` and still compiles everywhere, so the SQLite-backed app is unaffected on windows/arm64 — only the `duckdb` subcommands report the platform limitation at runtime.
Verified by cross-linking windows/arm64 with llvm-mingw (fails on main with undefined `duckdb_*` symbols, links with this change) and by a full dry-run of the release workflow on a throwaway repo (https://github.com/wesm/agentsview-release-test/releases/tag/v0.99.0): all six build legs passed, including the manylinux glibc-2.28 guard and the macOS minos check; wheels built and smoke-tested for all platforms. Release archives grow from ~8MB to ~24–30MB compressed because the DuckDB static library now ships in every supported binary.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Wes McKinney <wesm@users.noreply.github.com>
2 participants
Adds a native
windows/arm64build to the release pipeline, so Windows-on-ARM users get a real ARM64 binary instead of nothing (the installer currently 404s on arm64 because no asset is published).What changed
release.yml-- newwindows/arm64matrix entry on a nativewindows-11-armrunner:mattn/go-sqlite3+fts5) needs a C compiler. Set up a self-containedllvm-mingwaarch64 toolchain (clang + mingw runtime + lld) -- no Visual Studio / Windows SDK required -- and pointCCat it../agentsview --versionsmoke test executes natively (theGOARCH == GOHOSTARCHguard passes).build_wheels.py-- addwindows_arm64 -> win_arm64toPLATFORM_MAP, so a nativewin_arm64PyPI wheel is published andpip install agentsviewworks on Windows on ARM.--require-allnow expects this artifact, which the new matrix entry produces. Tests updated (46 passed).Validation
The
release.ymlworkflow only runs on tag push, so it cannot be exercised by PR CI. Instead I validated the exact recipe locally on Windows 11 arm64 hardware:npm run build: okCGO_ENABLED=1 GOARCH=arm64 CC=aarch64-w64-mingw32-clang go build -tags fts5: builds a native ARM64 PE (0xAA64) that runs (--versionexits 0)build_wheels.pyproducesagentsview-<ver>-py3-none-win_arm64.whlcontaining the ARM64 binaryrelease.ymlparses as valid YAMLThe runner image (
Windows11-Arm64) was confirmed to include 7-Zip and Bash, which the workflow relies on.Once this is released, the installer's arm64 path (PR #597) automatically prefers the native asset over the amd64-under-emulation fallback.
🤖 Generated with Claude Code